Partial Strictness in Two-Phase Locking

Two-phase locking is a standard method for managing concurrent transactions in database systems. In order to guarantee good recovery properties, two-phase locking should be strict, meaning that locks can be released only after the transaction's commit or abort. In this paper we show that even exclusive locks can be released immediately after the commit request has arrived, without sacriicing any important recovery properties. This optimization is especially useful if the commit operation takes much time compared with the other actions, as for main-memory databases, or if the commits are performed in batches. 1 Introduction When several transactions operate concurrently on the same database, a mechanism is needed for controlling the concurrency in order to guarantee correctness. That is, we have to ensure that when transactions are run concurrently the consistency of the database is preserved as if the transactions would be run serially. As to concurrency, the formal correctness is based on the notion of serializability, meaning that the interleaved mode of operation has the same result as when the transactions are run one by one. The most widely used strategy for scheduling concurrent transactions is based on locking. The scheduler locks a data item before a transaction may access it, and no other transaction may access the data item before the lock has been released. Locks are often divided into exclusive and shared locks; several transactions may hold a shared lock on a data item but when one holds an exclusive lock no other transaction may hold any (shared or exclusive) lock on the same data item. In two-phase locking 4], once the scheduler has released the lock for a transaction, it may not subsequently obtain any more locks for that transaction on any data item. It has been shown 13] that two-phase locking is a most general locking strategy that guarantees serializability when the set of transactions may change dynamically. In addition to guaranteeing serializability the scheduler must reject interleav-ings that are not recoverable. That is, if a transaction aborts, we must be able to reconstruct the situation we would have arrived at if the aborted transaction had not existed. Moreover, for practical reasons, it is advisable that aborting one transaction does not cause other transactions to abort, i.e., cascading aborts are